Found 31 posts.
Search results Show results as topic list.
Solaris and Karma » [SOLVED] Karma spherical uv projection
- MR SMITH
- 31 posts
- Online
This is a really naive way of doing it and probably breaks all proper usd / mtlx conventions but maybe it helps:
Solaris and Karma » mtlx2hda.py | How do I use it?
- MR SMITH
- 31 posts
- Online
O yeah duhh that makes total sense! I've been lucky enough that I haven't had to deal with other DCC's in a while.
Saw this video before rafal explained those steps, might clear things up: https://www.youtube.com/watch?v=QOUYP7My80M [www.youtube.com]
Example with full paths inlc flags:
"c:\Program Files\Side Effects Software\Houdini 20.0.660\bin\hython.exe" "c:\Program Files\Side Effects Software\Houdini 20.0.660\houdini\python3.10libs\vop2mtlx.py" -f D:\circlepattern.hda -n circlepattern2 -o D:\mtlx\circlepattern.mtlx
"c:\Program Files\Side Effects Software\Houdini 20.0.660\bin\hython.exe" "c:\Program Files\Side Effects Software\Houdini 20.0.660\houdini\python3.10libs\mtlx2hda.py" -o D:\mtlx\circlepattern_converted.hda -p D:\mtlx\
"c:\Program Files\Side Effects Software\Houdini 20.0.660\bin\hython.exe" "c:\Program Files\Side Effects Software\Houdini 20.0.660\houdini\python3.10libs\mtlx2karma.py" -o D:\mtlx\karmaNodeGraphs.json -p D:\mtlx\
Edit (easierpaths)
Saw this video before rafal explained those steps, might clear things up: https://www.youtube.com/watch?v=QOUYP7My80M [www.youtube.com]
Example with full paths inlc flags:
"c:\Program Files\Side Effects Software\Houdini 20.0.660\bin\hython.exe" "c:\Program Files\Side Effects Software\Houdini 20.0.660\houdini\python3.10libs\vop2mtlx.py" -f D:\circlepattern.hda -n circlepattern2 -o D:\mtlx\circlepattern.mtlx
"c:\Program Files\Side Effects Software\Houdini 20.0.660\bin\hython.exe" "c:\Program Files\Side Effects Software\Houdini 20.0.660\houdini\python3.10libs\mtlx2hda.py" -o D:\mtlx\circlepattern_converted.hda -p D:\mtlx\
"c:\Program Files\Side Effects Software\Houdini 20.0.660\bin\hython.exe" "c:\Program Files\Side Effects Software\Houdini 20.0.660\houdini\python3.10libs\mtlx2karma.py" -o D:\mtlx\karmaNodeGraphs.json -p D:\mtlx\
Edit (easierpaths)
Edited by MR SMITH - April 11, 2024 16:11:10
Solaris and Karma » mtlx2hda.py | How do I use it?
- MR SMITH
- 31 posts
- Online
No logs, as it just worked.
I first tried that right click convert to mtlx method. But that needed quite a lot of hand adjustment with the nodedef stuff missing, plus all the extra nodes that needed to be removed.
Than I tried to make an .hda first as suggested by jsmack, used that hda2mtlx.py script on that created .hda file.
That way i didn't really need to adjust anything by hand.
So that circlepattern.mtlx file, is created from the circlepattern.hda by using hda2mtlx.py.
Than that created mtlx file is put through mtlx2hda and mtlx2karma to create circlepattern_converted.hda and the json file.
Curious what your reason is to convert, instead of using an hda?
For me it was the mainly the speed, but loosing gl im still not sure if its worth it. Also converting you really loose the ability to quickly dive in and add or change functionality.
I'm also not using it in production yet, really hope next major release will solve these type of issues. Having to convert and create blackboxes isn't the way imo.
I first tried that right click convert to mtlx method. But that needed quite a lot of hand adjustment with the nodedef stuff missing, plus all the extra nodes that needed to be removed.
Than I tried to make an .hda first as suggested by jsmack, used that hda2mtlx.py script on that created .hda file.
That way i didn't really need to adjust anything by hand.
So that circlepattern.mtlx file, is created from the circlepattern.hda by using hda2mtlx.py.
Than that created mtlx file is put through mtlx2hda and mtlx2karma to create circlepattern_converted.hda and the json file.
Curious what your reason is to convert, instead of using an hda?
For me it was the mainly the speed, but loosing gl im still not sure if its worth it. Also converting you really loose the ability to quickly dive in and add or change functionality.
I'm also not using it in production yet, really hope next major release will solve these type of issues. Having to convert and create blackboxes isn't the way imo.
Solaris and Karma » mtlx2hda.py | How do I use it?
- MR SMITH
- 31 posts
- Online
Heres one of the test I did, worked in cpu and xpu but not on gl. This stuff is all new for me aswel, so my ability to provide help is limited haha.
Solaris and Karma » mtlx2hda.py | How do I use it?
- MR SMITH
- 31 posts
- Online
It's difficult to tell where it went wrong on your end. But it should be an digital asset after all the steps. I did't really tested the noise pattern, but should be similair results. Did you put in the nodedef stuff? or did you first made an hda, and than used the hda2mtlx.py ?
Solaris and Karma » mtlx2hda.py | How do I use it?
- MR SMITH
- 31 posts
- Online
Sorry nvm, that was the error i had because my mtlx needed texcoords. Which the sphere only had on cpu.
Edited by MR SMITH - April 11, 2024 11:50:04
Solaris and Karma » mtlx2hda.py | How do I use it?
- MR SMITH
- 31 posts
- Online
mtlx_normalize does work in gl on my end. actually quite a lot of mtlx nodes already work in gl. The space transforms are really the limiting factor from what I found , which is a shame. If those are fixed it really should open the box for procedural shading and texturing in gl. There some other quirks like normalmaps that do work in gl, but you need to provide an tangent attrib.
Would advice to set reset viewport on an hotkey from the labs toolset and hit it often haha. That normalize might be an update issue for you aswel. GL really needs an reload render button like karma does so you don't loose all settings while hitting.
Rafal explained it to me in another thread with some files: https://www.sidefx.com/forum/topic/95316/#post-419183 [www.sidefx.com]
Try if this works for you, otherwise I can search for one I tried.
Would advice to set reset viewport on an hotkey from the labs toolset and hit it often haha. That normalize might be an update issue for you aswel. GL really needs an reload render button like karma does so you don't loose all settings while hitting.
Rafal explained it to me in another thread with some files: https://www.sidefx.com/forum/topic/95316/#post-419183 [www.sidefx.com]
Try if this works for you, otherwise I can search for one I tried.
Solaris and Karma » Mtlx Hda questions
- MR SMITH
- 31 posts
- Online
I think that's all fine. You can create HDAs in Indie, but they are saved in an indie format, so will downgrade the session if loaded into a fully commercial session.Yeah it's strange cause normally it should be saved as .hdalc so you know it's a indie asset. But for some reason i managed to make an .hda (also tried that hda2mtlx.py script on an .hdalc and it complained. Thatswhy i thought it might be an temp fix or something)
Yes, it's reliable, and will continue to be. That's pretty much how MaterialX standard nodes are processed for Houdini releases.Thats great to know! Makes it easier to put in some effort, knowing don't have to redo with next major releases.
Edited by MR SMITH - April 10, 2024 11:45:56
Solaris and Karma » mtlx2hda.py | How do I use it?
- MR SMITH
- 31 posts
- Online
In Houdini 20 I can see my custom materialx in KarmaCPU, but not in HoudiniGL or KarmaXPU.
Are you sure it's the materialx that doesn't work in gl an xpu?
I also just tested some convertions, when it worked on cpu it also worked on xpu. Gl didnt work at all on my end.
There are still quite a lot of discrepancies between karma cpu xpu gl besides converted mtlx files.
One most obvious example is the default sphere. In cpu it seams to work with uv coords, on the xpu and gl side it doesn't.
Solaris and Karma » Mtlx Hda questions
- MR SMITH
- 31 posts
- Online
Thanks Rafal! truly appreciate the effort creating those files. I managed to do some tests.
As jsmack pointed out, I also found it easiest to create an hda first. Than using the vop2mtlx.py script. As far as I could tell I didn't need to change anything by hand this way. No extra shader nodes inlcuded, already had the nodedef stuff in it.
After that I followed step 4 and it seemed to work fine. Makes it probably easy to automate if needed.
*One thing that was a bit weird is that I was able to make an .hda file without issues even though i'm on Indie. Is this something temporary or did that limitation change?
Speed was good as far as I could tell from the tests I've done.
Similar speed to using an mtlxconstant in an parameter which I kinda hoped / expected.
Also good to see that the whole graph shows as a single prim in the scene graph. So it's definitely an option.
I couldn't manage to make it work in GL, even though the original hda works fine. Hopefully this is my fault. Loosing GL and also loosing the flexibility from an HDA makes me think the speed gain alone isn't worth the hassle.
Followup questions I'm still curious about:
- Anybody got custom or converted mtlx nodes that also work in GL? (Thought this wouldve been one of the strong points of mtlx, only half joking haha)
- Is this roundtrip with mtlx / hda / json still reliable for future hou versions and mtlx standards? Or better not to expect backwards compatibility yet?
I'm prob gonna just wait on bug: 133382, hopefully it's something thats fixable and reassess after. I'm pretty sure that will already solve most of my gripes.
Cheers!
ps extra info from sidefx team for anybody interested:
"As for the issue of recooking of asset (subnet) parameters, its related to the complexity of subnets having both parameters and children. While we were able to efficiently handle parameter changes to VOPs that have a corresponding USD shade primitive (eg, mtlx constant), we were hitting edge cases when trying to optimize the subnets (node graphs). There is currently bug 133382 filed for this issue.
One workaround is to use mtlx constant VOPs. Another is to use Edit Material Properties LOP to selectively edit values on shaders and materials (you can promote/loft the asset input to a material with a Parametr VOP). There is also primvar reader approach, where you affect the shader values using geomety poperty reader node.
Also, converting the asset to mtlx shader would work around the re-translation issue. The custom mtlx vop would have a corresponding USD shader prim, and therefore it would be possible to optimize the translation.
The dowside of building your own custom mtlx shader is that it can be a very cumbersome process."
As jsmack pointed out, I also found it easiest to create an hda first. Than using the vop2mtlx.py script. As far as I could tell I didn't need to change anything by hand this way. No extra shader nodes inlcuded, already had the nodedef stuff in it.
After that I followed step 4 and it seemed to work fine. Makes it probably easy to automate if needed.
*One thing that was a bit weird is that I was able to make an .hda file without issues even though i'm on Indie. Is this something temporary or did that limitation change?
Speed was good as far as I could tell from the tests I've done.
Similar speed to using an mtlxconstant in an parameter which I kinda hoped / expected.
Also good to see that the whole graph shows as a single prim in the scene graph. So it's definitely an option.
I couldn't manage to make it work in GL, even though the original hda works fine. Hopefully this is my fault. Loosing GL and also loosing the flexibility from an HDA makes me think the speed gain alone isn't worth the hassle.
Followup questions I'm still curious about:
- Anybody got custom or converted mtlx nodes that also work in GL? (Thought this wouldve been one of the strong points of mtlx, only half joking haha)
- Is this roundtrip with mtlx / hda / json still reliable for future hou versions and mtlx standards? Or better not to expect backwards compatibility yet?
I'm prob gonna just wait on bug: 133382, hopefully it's something thats fixable and reassess after. I'm pretty sure that will already solve most of my gripes.
Cheers!
ps extra info from sidefx team for anybody interested:
"As for the issue of recooking of asset (subnet) parameters, its related to the complexity of subnets having both parameters and children. While we were able to efficiently handle parameter changes to VOPs that have a corresponding USD shade primitive (eg, mtlx constant), we were hitting edge cases when trying to optimize the subnets (node graphs). There is currently bug 133382 filed for this issue.
One workaround is to use mtlx constant VOPs. Another is to use Edit Material Properties LOP to selectively edit values on shaders and materials (you can promote/loft the asset input to a material with a Parametr VOP). There is also primvar reader approach, where you affect the shader values using geomety poperty reader node.
Also, converting the asset to mtlx shader would work around the re-translation issue. The custom mtlx vop would have a corresponding USD shader prim, and therefore it would be possible to optimize the translation.
The dowside of building your own custom mtlx shader is that it can be a very cumbersome process."
Solaris and Karma » Mtlx Hda questions
- MR SMITH
- 31 posts
- Online
Thanks rafal! Clears up enough to follow through and test some assets. (bummer about GL hopefully future feature)
Solaris and Karma » Mtlx Image string inputs connection return error
- MR SMITH
- 31 posts
- Online
Noticed this aswel with creating assets, havent had time to report it yet so if you can that would be great!
Solaris and Karma » Mtlx Hda questions
- MR SMITH
- 31 posts
- Online
The mtlx nodes are lacking functionality and are low-level, which is fine. However, I can't seem to find a workflow to build upon.
I've tried creating HDAs. Initially, they seemed to work, but when things get more complex, the recooking process every time you change a slider becomes a non-viable workflow for me.
Annoyingly, if you add an mtlx constant into the parameter you're 'lookdevving', you can change the specific value through the constant without having to recook the entire network. Same goes for primvars. But keeping all those constants around makes the overal evaluation again slower.
Questions:
I'm assuming that native mtlx nodes are the only 'correct workflow' and will be much faster in the Python evaluation step compared to HDAs (will they though?)
Is the Python route with the voptomtlx still the way to go to convert HDA to mtlx? (or can use right click now)
https://youtu.be/QOUYP7My80M [youtu.be] I've checked this vid and seems like awefull lot of steps to roundtrip an asset to mtlx.
Is it easier to use something like Quiltix to build functionality that could be imported into Houdini or will that require similair amount of steps?
Does OpenGL still work with custom mtlx nodes if it worked in the original HDA consisting of low-level mtlx nodes?
Any tips or links around this topic would be more than welcome
Cheers, K!
I've tried creating HDAs. Initially, they seemed to work, but when things get more complex, the recooking process every time you change a slider becomes a non-viable workflow for me.
Annoyingly, if you add an mtlx constant into the parameter you're 'lookdevving', you can change the specific value through the constant without having to recook the entire network. Same goes for primvars. But keeping all those constants around makes the overal evaluation again slower.
Questions:
I'm assuming that native mtlx nodes are the only 'correct workflow' and will be much faster in the Python evaluation step compared to HDAs (will they though?)
Is the Python route with the voptomtlx still the way to go to convert HDA to mtlx? (or can use right click now)
https://youtu.be/QOUYP7My80M [youtu.be] I've checked this vid and seems like awefull lot of steps to roundtrip an asset to mtlx.
Is it easier to use something like Quiltix to build functionality that could be imported into Houdini or will that require similair amount of steps?
Does OpenGL still work with custom mtlx nodes if it worked in the original HDA consisting of low-level mtlx nodes?
Any tips or links around this topic would be more than welcome
Cheers, K!
Solaris and Karma » Opacity difference XPU vs CPU
- MR SMITH
- 31 posts
- Online
Technical Discussion » MaterialX GL/Viewport shader questions
- MR SMITH
- 31 posts
- Online
jsmack
GL/Mtlx parity is still a WIP. Report any inconsistencies as bugs using the bug/rfe page on the forum.
Is there a list that suposed to be supported somewhere?
Found a bunch of mtlx nodes that doesn't appear correct in the gl viewport. Don't want to spend time to rfe them all if they aren't even suposed to work in the first place.
Edited by MR SMITH - March 19, 2024 03:53:50
Solaris and Karma » A Variety of Karma Triplanar Questions
- MR SMITH
- 31 posts
- Online
Thanks again for the clarification jsmack!
Yeah sorry I mean once exported to usd, in the usd file there is a a shader description that should work with other delegates that can render mtlx.
So from what I've been gathering.
Working in the "USD MaterialX Builder" and only use those nodes available, it's pretty safe that what ever you do mostlikely will be compatible with other delegates that can render mtlx?
Refering mostly to these nodes:
What about hda's and houdini parameters?
As a test I've create somehwat similair triplanar as the rs one. (those controls are also illogical imo)
But is this still considerd as an compatible mtlx shader for other delegates? Only used mtlx nodes.
Any tips on checking or testing these compatibility stuff for mtlx?
What other delegate in houdini is most complete in mtlx?
Sorry for all these questions
Want to do some higherlevel / quality of life nodes for karma.
But it would be nice if can take mtlx compatibility into account.
Yeah sorry I mean once exported to usd, in the usd file there is a a shader description that should work with other delegates that can render mtlx.
So from what I've been gathering.
Working in the "USD MaterialX Builder" and only use those nodes available, it's pretty safe that what ever you do mostlikely will be compatible with other delegates that can render mtlx?
Refering mostly to these nodes:
What about hda's and houdini parameters?
As a test I've create somehwat similair triplanar as the rs one. (those controls are also illogical imo)
But is this still considerd as an compatible mtlx shader for other delegates? Only used mtlx nodes.
Any tips on checking or testing these compatibility stuff for mtlx?
What other delegate in houdini is most complete in mtlx?
Sorry for all these questions
Want to do some higherlevel / quality of life nodes for karma.
But it would be nice if can take mtlx compatibility into account.
Edited by MR SMITH - March 16, 2024 07:43:26
Solaris and Karma » A Variety of Karma Triplanar Questions
- MR SMITH
- 31 posts
- Online
Sorry to highjack the thread but I'm now really curious.
@Jsmack Does that mean htmlx_ nodes also breaking the compatibility?
Was hoping that they where just some higher level nodes build ontop. Referring to all the nodes in "USD MaterialX Builder".
In the docs it says in: MtlX Color Ramp VOP node -
For Karma use only it is advised to use “Karma Float/Color Ramp” for better performance and experience.
I assumed it would be converted to mtlx when saved as usd?
Hope anyone can clarify,
Thanks in advanced!
jsmack
Yes, any custom node will break standard, that's why they're usually prefixed with 'hmtlx' or 'karma'
@Jsmack Does that mean htmlx_ nodes also breaking the compatibility?
Was hoping that they where just some higher level nodes build ontop. Referring to all the nodes in "USD MaterialX Builder".
In the docs it says in: MtlX Color Ramp VOP node -
For Karma use only it is advised to use “Karma Float/Color Ramp” for better performance and experience.
I assumed it would be converted to mtlx when saved as usd?
Hope anyone can clarify,
Thanks in advanced!
Solaris and Karma » MTLX - Position and Normal data before dicing / displacement
- MR SMITH
- 31 posts
- Online
Suu-jp
I hope this tip will help you to find a solution.
https://www.sidefx.com/docs/houdini/nodes/vop/kma_rayimport.html [www.sidefx.com]
Thanks for the tip Suu-jp. But those return the diced geo afaik. Happy to be proven wrong though
Kinda just want to get the raw pos and normal data without having to add rest coords all over the place.
But maybe I'm missing something. How would someone use the triplanar with displacement without having access to the raw pos?
Solaris and Karma » MTLX - Autobump workflow?
- MR SMITH
- 31 posts
- Online
Ah gotcha!
Yeah if it should work as the bottom one without needing an extra normal / bump map input that would be great!
I've turned the dicing way lower on this one than the default, just ballparked it how I would be able to use it in prod.
Yeah if it should work as the bottom one without needing an extra normal / bump map input that would be great!
I've turned the dicing way lower on this one than the default, just ballparked it how I would be able to use it in prod.
Solaris and Karma » MTLX - Autobump workflow?
- MR SMITH
- 31 posts
- Online
Thanks for replying jsmack!
Not sure why it needs to be a render feature though.
Always thought it was just the normals that arent being calculated properly?
Atleast this how i use it now:
Displacement only:
Displacement plus bump, same map same height. Not correct, doubling up the normals.
Displacement plus bump, but using the restnormals (normals before the displacement / dicing):
Basically want to have the bottom result, without the need of an extra primvar if that make sense.
Not sure why it needs to be a render feature though.
Always thought it was just the normals that arent being calculated properly?
Atleast this how i use it now:
Displacement only:
Displacement plus bump, same map same height. Not correct, doubling up the normals.
Displacement plus bump, but using the restnormals (normals before the displacement / dicing):
Basically want to have the bottom result, without the need of an extra primvar if that make sense.
Edited by MR SMITH - March 12, 2024 13:12:34
-
- Quick Links